home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1861 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.2 KB
  1. Path: gidora.kralizec.net.au!root
  2. From: jon@zeta.org.au
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: locking
  5. Date: 13 Jan 1996 14:17:44 GMT
  6. Organization: Kralizec Dialup Internet Sydney, +61-2-837-1183 V.32bis
  7. Message-ID: <4d8eu8$phs@gidora.kralizec.net.au>
  8. References: <4d0j6r$1ri@daphne.ecmwf.int> <30F3E9C3.15FB7483@intellektik.informatik.th-darmstadt.de>
  9. Reply-To: jon@zeta.org.au
  10. NNTP-Posting-Host: dialup08.syd1.zeta.org.au
  11. X-Newsreader: IBM NewsReader/2 v1.2.5
  12.  
  13. In <30F3E9C3.15FB7483@intellektik.informatik.th-darmstadt.de>, Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> writes:
  14. >Baudouin Raoult wrote:
  15. >
  16. >I would say the temporary object should be destroyed directly after
  17. >the invocation of 'bar'.
  18.  
  19. It is up to the compiler to decide when it is destroyed. According to the (ARM 12.2)
  20. it must be destroyed by the end of the scope which created it, but it
  21. is implementation dependent as to when it actually is destroyed. 
  22. Not knowing exactly when the temporary is destroyed means that 
  23. it is impossible to make strong assertions about the state of the 
  24. object referred to by fooH after fooH->bar() returns.
  25.  
  26. Refer to my articles in comp.lang.c++.moderated on this subject for my 
  27. other comments about the (non-)safety of this locking technique.
  28.  
  29. jon.
  30.  
  31.  
  32.  
  33.